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SUBSUMPTION 
ARCHITECTURE AND 
ROBOTIC BEHAVIOUR 
To subsume a task is to supersede it 
with a higher priority task. When we 
speak of subsumption in robotic pro- 
eramming we are describing the 
process by which one behaviour sub- 
sumes, or over-rides another based on 
an explicit priority that we have 
defined. This behavioural architecture 
was first described by Dr. Rodney 
Brooks in his article “A robust layered 
control system for a mobile robot” in 
IEEE Journal of Robotics and Automation, 
RA-2, April, 14-23, 1986. The Brooksian 
ideal subsumption architecture does 
not require that any behaviour know 
anything about any other behaviour. A 
robot programmed in this manner 
responds reflexively to its environment 
using simple behaviours. What this 
also means is that new behaviours can 
be added to a robot without changing 
any other behaviour. This makes enhanc- 
ing a robot's programming very sim- 
ple. An example of subsumption pro- 
gramming in our little BoE-Bot would 
be, for instance, if we had a behaviour 
that simply randomly chooses a direc- 
tion to travel and a duration of time to 
travel in that direction. When com- 
plete, that subroutine (behaviour now) 
would choose a new direction and 
duration. But we don’t want to get 
stuck up against a wall or table leg, so 
we add a behaviour that looks at a 
bumper and if we run into something 
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Figure 22. Simple repre- 
sentation of procedures 


will make our robot 
back up and turn 
away. We want the 
bumper behaviour to have priority over 
the wander behaviour, so it will sub- 
sume that behaviour and take over the 
control of the wheel motors to get itself 
away from the wall. Because the 
bumper behaviour has a higher priority 
than the wander behaviour we can be 
assured that our little BoE-Bot can get 
away from obstacles that block its path. 
Further, if wander had set a very long 
duration on the last direction that it 
wanted to go, when bumper was done, 
the wander behaviour would take up 
the control again, continuing on its 
merry way as if nothing had hap- 
pened. 

Because each behaviour is indepen- 
dent, and many simply react to the 
robot's environment, we can build up 
a set of behaviours whose interactions 
with each other are not programmed, 
and we will begin to see combinations 
of behaviours unforeseen! This is called 
emergent behaviour because we didn’t 
plan it, it came about because of the 
robot’s interaction with its environ- 
ment. When emergent behaviour is 
allowed to occur, our robots appear to 
take on a life of their own and stop act- 
ing as if they just do the same thing 
over and over again. More importantly 
in the real world, some behaviours can 
be programmed to do a certain task, or 
retrieve an object, and not have to be 
concerned with the moment-to- 


based on subsumption. 


moment job of avoiding 
falling into a hole or 
running into a rock. 

Our simple sets of behaviours we 
just discussed can be graphically dis- 
played by a subsumption network dia- 
gram. An example of our simple wan- 
der/bumper behaviours is shown in 
Figure 22. The ovals on the left are 
inputs, the rectangles in the middle are 
behaviours and the ovals on the right 
are outputs. 

Where a line from a higher priority 
behaviour intersects a line from a lower 
priority behaviour to its output actua- 
tor (in this case, Motors) the higher pri- 
ority behaviour is said to have subsumed 
control from the lower priority behav- 
iour. This is shown on the network 
above by Get away’s line intersecting 
Wander’s line with a circle around the 
junction. There can be multiple inter- 
sections in multiple locations on the 
direction lines that can show the sub- 
sumption logic very clearly. Feel free to 
innovate how you show your network 
for your robot, there are many ways to 
build a subsumption network diagram. 


WHERE DO WE GO 
FROM HERE? 

Get used to these diagrams and ways 
of thinking. In the chapters ahead we 
will be using these ideas and expand- 
ing on the simple diagrams that we 
have seen so far. In each section I will 
break our work down into easy to see 
pieces, such as variables needed, I/O 
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Listing 10. 


‘Servo routine cons and vars 


LEFT con 15 pore. 15,left motor 
RIGHT con 3 'port 3,right motor 


SACT con 5 ‘times through the 
loop 


drive var word 'both sides in var 


act:’servo controller subroutine 
if aDur > 0 then aDec 


aDur = SACT 


‘do state 1 


pulsout LEFT,lmotor * 10 
pulsout RIGHT, «cmoter * 10 
goto aDone ‘state 1 done 


ldrive var drive.bytel ‘left side is here aDec: 

rdrive var drive.byte0 ‘right side here aDur = aDur - 1 ‘do state 2 
aDone: 

aDur var byte ‘duration counter 
nemaran 


ports used and new instructions. I will 
also show the process by which the 
state machines are defined and our 
subsumption network diagrams can be 
used to understand our behavioural 
priorities. 


PHASE 1: MAKING 

THE BOE-BOT MOVE, 
AND THE FINITE 
STATE MACHINE 

A robot that doesn’t do anything isn’t 
very interesting. Now that you have 
modified your servos, attached them to 
Stamp II I/O ports and have checked 
their operation, we will make our BoE- 
Bot wander randomly around its envi- 
ronment. To implement this simple 
functionality we need to have two 
modules: One that determines a direc- 
tion and a duration to go in that direc- 
tion and another to send commands to 
our wheels. 

We will call these modules wander 
and act respectively. Act simply oper- 
ates the motors. It isn’t really a behav- 
iour, its an output and will be labelled 
on our diagram as motors. Wander is a 
behaviour so it will appear on our sub- 
sumption diagrams as a behaviour. 


The State Machine 

and Stamp II Code for Act 

We know that to get our servos to turn 
the wheels we need to output a pulse 
whose width needs to be approxi- 
mately 1 ms to 2 ms long, with 1.5 ms 
being the stop position. We also know 
that this pulse needs to be repeated 
every 20 ms to 30 ms for our servos to 
continue moving. This suggests that 
we will have two operations that we 
will need to program. One will be ‘out- 
put the pulse’, the other will be ‘wait 
for 20 ms’ after which we go back to 
state 1. We have two servos, so we 
could say that we have three opera- 
tions, output left servo pulse, output 
right servo pulse and wait. To keep this 
module simple we will limit it to two 
states, one to output the pulses and 
one to delay before the next pulse time. 
Since we know that we need to repeat 
the pulse every 20 ms to 30 ms and we 
know that we don’t want to spend all 
of our time in the act module waiting 
for this time to elapse, we therefore 
know that we will be exiting and enter- 
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ing this block of code several times 
before the full set of state transitions 
occurs. We know that each instruction 
takes about 250 us to execute for the 
Stamp II, this tells us about how long 
each module that we will be calling 
will take to run, we count up the 
instructions and multiply by 250 us. 
For now we'll guess and say that it will 
take 5 passes through state 2 for 20 ms 
to elapse. As we write other modules 
we will be revising this estimate, but 
this is a good starting point for now. 
Let’s graph our state machine so that 
we can understand what we want, and 
maybe even see any mistakes we made 
in our logic! 

Before we can build our state 
machines it is helpful to define all of 
the actions that we wish to have our 
behaviour or output function perform. 
Each of these functions can be grouped 
by their activities into an individual 
state. Here is a way to define a motor 
control function, which we saw above 
as the subroutine act. 


State 0 

Output left servo pulse value 
Output right servo pulse value 
Set the number of iterations 
(aDur) = 5 
State 1 

Decrement aDur 

If aDur = 0 then go to state 0 


We now have a detailed list of actions 
that need to occur in our state machine 
for act. We can now draw a state dia- 
eram that has the needed detail, such 
as Figure 23. 

This state diagram tells us when 
each transition is taken 


and exactly what each state is doing. 
The transition from state 0 (on the left) 
and state 1 always occurs, there is no 
condition. However, the transition 
from state 1 (on the right) to state 0 
occurs when aDur = 0. Notice that 
state 1 has a loop that exits and turns 
back on itself. This indicates that this 
state iterates on itself, in our case, this 
means that we will enter this part of 
the module several times before it is 
complete. Look at this diagram care- 
fully. It shows us very clearly what our 
act module must do, and in what order 
it must do it. Think about how it would 
look if we were to output the left 
motor pulse in a different state than 
the right motor pulse, how would that 
look? For our purposes, we can say 
that each circle (state) is a place where 
we enter the module in our program 
and decide what to do next. You 
should now be starting to see how 
powerful this concept is for us! 

The code that implements our act 
module is shown in Listing 9. I will 
show the variable declarations on the 
left and the actual code on the right 
from now on. To make a program easier 
to read and to modify, you should 
make liberal use of con statements and 
not use “magic numbers” embedded in 
your code. This is how I will show our 
programs. Remember that everything 
that follows a’ is a comment, not an 
instruction. I will explain why we mul- 
tiply the lmotor and rmotor values by 
10 in the next phase. 

If we are to write a large program 
we need to conserve variable space, 
the PBASIC language has some very 
clever ways to use that variable space. 

The pulsout instruc- 


Figure 23. State diagram 
for the ‘act’ procedure. 
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tions output a pulse to our servo 
motors of the proper width for the 
speed and direction that we want. The 
drive variable is a word which is two 
bytes, a byte0 and a bytel. You will see 
why this is a useful way to represent 
the motor drive variables when we 
design the code for the wander module 
in the next phase! 


PHASE 2: MAKING THE 
BoE-BOT WANDER 

All we need wander to do is randomly 
choose a direction and a duration to go 
that direction. This module will be as 
easy to design as the act module, and it 
will demonstrate the ease with which 
we can add new behaviours, and how 
these behaviours can remember what 
they are doing. The first step in design- 
ing our form of a finite state machine is 
to write down all of the steps that are 
to be taken and all of the transition 
functions that need to be tested. After 
we have our list, the state machine can 
be drawn. 

Here is our action list for wander: 


State 0 

Choose a direction to go by using 
the random function (wDir) 

Go to State 1 
State 1 

Choose a duration to go by using 


Listing 11 


‘Servo drive commands 
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the random function (wDur) 

Add some minimum time to the 
duration so its not too short 

Go to state 2 
State 2 

Decrement wDur 

If wDur = 0 then go to state 0 


The state machine diagram for our 
wander behaviour is shown in Fig- 
ure 24. 

Some of the arrows do not have 
transition labels attached to them. 
When a state machine automatically 
transitions from one state to another 
and does not need to make a decision 
a transition function is not needed. 

The purpose of the wander module 
is to randomly choose a direction for 
our robot to go and a random time 
duration for it to take going there. The 
random() instruction plays an important 
role in the wander logic. Random uses a 
word variable type and needs a ‘seed’ 
to set up its return value. We will just 
use the last return value it gave us as 
the seed for the next one. We will also 
use a mask to only get numbers in a cer- 
tain range; a small range for the direc- 
tion changes, a much larger one for the 
duration. Another interesting feature is 
the lookup instruction. This instruction 
uses a word sized variable, because we 
break the drive variable into a byte0 and 


Figure 24. State dia- 
gram for the ‘wander’ 
procedure. 


bytel variables, we 
can get both the left 
and right motor val- 
ues from a single 
lookup! You'll see how this is done in 
the Listing 10, and you'll see how this 
makes it very simple for us to change 
what the robot will do. 

On the left all of the useful motor 
control commands are listed with a $ in 
front of them. This means that those 
numbers are hexadecimal, I have used 
hexadecimal (HEX) numbers because 
its easy to see the left and right halves of 
them (bytel and byte0) that we have 
assigned as the left and right motor 
values. Of course, this means that we 
need to understand HEX in order to 
know what is going on. In HEX, each 
digit represents a number from 0 to 15, 
A, B,C, D, E, and F represent the num- 
bers 10, 11, 12, 13, 14, 15 respectively. 
The digit to the far right is the ’1’s digit, 
just like in our decimal system, but it 
can be from 1 to 15. The next digit to 
the left is the 16’s digit, multiply any 
number you see there by 16, then add 
the number in the ‘1’s digit place to 
that to get the decimal number. Our 
numbers above are 4 digits, but 
remember, that is just because we are 
putting both the left and right motor 
values in at once, we can look at the 
two left digits as separate numbers 
from the two digits to the right. This 
means that the HEX number $1C = 
16+12, or 28. Remember in the last sec- 
tion when I said I’d explain why act 
multiplies the Idrive and rdrive num- 
ber by 10? Now is the time for that 
explanation. A byte can only hold val- 
ues from 0 to 255, our servos need to be 
sent numbers from 500 to 1000. To get 
that range, we use 50-100 (which are 
numbers less than 255) for each motor 
speed setting, then multiply by 10 to 
get values from 500 to 1000. This does- 
n't represent all possible values, but 
this really doesn’t matter when driving 
modified servo motors as wheels. 


if wDur > 0 then wDonel 


drive = wDir 


‘get direction 
‘reset state 


‘choose direction 
‘random direction 


i = seed & 111 'mask off for 0-7 


leokup 1, [tr,fd,fd,;fd,rr,td, td,tl],wbir 


‘next state 


‘randomize 


fd con $6432 ‘forward wstate = 0 
rv con $3264 ‘reverse wDonel: ‘completed 
st con S4b4b stop . ee 
eae con $644b 'turn right ; 
webDars 
wd con $4b32 ‘turn left d d 
eile con $6464 ‘rotate right Peay ee 
zil con $3232 rotate left = 
‘wander values 
wstate var byt e 'FSM status ‘choose direction 
wDir var word ‘wander value sees Il 
wDur var byte ‘wander duration return 
weDur: ‘’choose duration 
random seed 
wander: 


branch wstate, [wcDir,wcDur] 
‘This is state 2 


wDur = wDur — 1 
y te 


wDur = (seed & 111111) + 20 
‘mask for 64 and add 20 for more time 


wstate = 2 
return 


‘next state 
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We now have almost all we need to 
make our robot wander aimlessly 
through a room. Almost. Our wander 
and act functions are subroutines, this 
means that something has to call them. 
The loop defined by main and goto 
main is our “brain” for our robot. All 
behaviours are called from here. List- 
ing 11 is the full program that has all of 
the variables and the subroutines as 
well as the setup and main run loop to 
show you how it all fits together. Type 


Listing 12 

‘Generic values 

I var byte 

Tmp var word 

Seed var word 

‘These are for the servo routines 
LEFT con 15 

RIGHT con 3 

SACT con 5 

Drive var word 


drive.bytel 
drive.byte0 


Ldrive var 
Rdrive var 


ADur var byte 
‘Servo drive commands 
fd con $6432 
ry con $3264 
st con S4b4b 
EE con $644b 
wd con $4b32 
mg con $6464 
raal con $3232 
‘wander values 

wstate var byte 
wDir var word 
wDur var byte 


'set up for running 
wstate =0 
main: 
gosub wander 
gosub act 
goto main 


this into the Stamp II programmer and 
watch your little robot wander around 
the room for a while. Make sure it 
doesn’t run into anything! In next 
month’s instalment we'll teach it to 
avoid running into the wall. 

Note the set up for running section in 
the code. We need to make sure that 
the wander behaviour starts out in the 
correct state, so, we set that state here. 
Now, we need to make sure that wan- 
der and act are called regularly, so these 


‘loop counter, whatever 
‘temporary holder 
‘random number seed 


‘left wheel port 
‘right wheel port 


‘times through act routine 


‘wheel command combo 
‘left wheel command 
‘right wheel command 
‘duration of pulse left 


‘forward 
‘reverse 
‘stop 

'turn right 
'turn left 
‘rotate right 
'rotate left 


‘shared byte 
‘wander value 


‘wander duration 


‘initial wander state 


two subroutine calls are placed in a 
loop starting at main. This loop will be a 
very important feature of our code 
when we start adding new behaviours 
to our robot! 
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‘this is the main activity loop 


‘randomly wander around 
‘state 2 immed. follows 


‘get direction 
‘reset state 


wander: 
branch wstate,[wcDir,wcDur ] 
wDur = wDur - 1 
if wDur > 0 then wDonel 
drive = wDir 
wstate = 0 
wDonel: 


return 

weDir: ‘’choose direction 
random seed 
i = seed & 3111 


lookup a (te, cd, ta, ta pjcr, 6a, fay, whan 


wstate = 1 
return 

weDur: '’choose duration 
random seed 


‘completed 


‘random direction 
‘mask off for 0-7 only 


‘next state 


‘choose direction 


‘random direction and duration 


‘mask for 64 choices 
‘next state 


‘moves servo motors 


‘already doing one, got here 


‘times through this one 


pulsout LEFT, Idrive * 10 
pulsout RIGHT,rdrive * 10 


wDur = (seed & 111111) + 20 
wstate = 2 
return 
act: 
if aDur > 0 then aDec 
aDur = SACT 
aDec: 
aDur = aDur - 1 
aDone: 
return 
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‘decrement stuff 





